As may be known, Integrated Circuit Cards (ICCs) comprise at least a CPU, a volatile memory, and a non volatile memory (NVM). ICCs are used for a wide range of applications involving different devices. For example, when used for telecommunication applications, ICCs are coupled to a GSM/UMTS handset device including a man to machine interface which allows a user to manage the ICC. The ICC may also be used in a machine-to-machine (M2M) application, wherein a system device is coupled to the ICCs and no man to machine interface is provided. Moreover, ICC machine-to-machine (M2M) applications generally comply with different hardware and/or software requirements with respect to ICCs incorporated into handset devices, depending on the specific application they serve.
For example, an emergency ICC device reporting failures of a lift in a building has a stable voltage supply, and the internal ICC is continuously powered on, for example for several years. Moreover, the reliability requirement of the ICC should be very high since it is desirable that it not be replaced even for several years. An ICC device installed inside a car device for phone calls may also be used to generate alerts in case of theft or a car accident. In this case, the ICC is usually not continuously powered on, and the voltage supply is substantially not stable. Still further, a gas meter device storing an ICC may be used to send the gas meter measurement on a regular basis or upon a specific event. This information may automatically be transmitted via an SMS or a data protocol. All the applications referred above, i.e. man-to-machine applications, such as a telecommunication applications and M2M applications, suffer from the limitations that the loss of reliability of the non volatile memory of the ICC is not controlled at application layer.
For clarity, below are some examples of loss of reliability. Non-volatile memory typically cannot guarantee that memory cells not updated for more than a predetermined time period, for instance for more than ten years, correctly store data. This problem is also known as reliability on data retention of the non-volatile memory. For example, in a flash memory, the electric charges of memory cells are associated with respective bits and thus to corresponding data stored in the flash memory. However, if a cell is not updated for some time to restore the corresponding electric charge, this charge slowly dissipates and data associated therewith is lost.
Non-volatile memory reliability also involves other factors, for example, a limitation on the number of writing cycles supported by the memory. In fact, after a predetermined number of writing cycles on a same memory cell, further operations on such cell, i.e. reading access or writing access, may not be executed correctly. Thus, data previously stored may be lost. Other factors involving reliability of memory are the deterioration of the hardware or connection between the ICC and the device thereto coupled, i.e. the handset or the system device.
As cited above, the current methods for controlling loss of reliability are not available or managed from the applications of the ICC. This is due to the fact that typically only the operating system has the control of the hardware, and thus on the non volatile memory, and the applications are coupled to respective portions of such non-volatile memory generally only through the operating system. This serves to increase the portability of applications on different operating systems, in compliance with predetermined interfaces between the core operating system and the applications, such as Java Card and ETSI TS 102 241.
Thus, at the application layer, it may be desirable to detect or interpret the status of the non-volatile memory, due to the nature of the above mentioned interface, and thus control the reliability of the non-volatile memory. That is to say, the ICC operating system (OS) merely provides the application program with interfaces for accessing and updating data in memory, and the ICC OS is responsible for managing the physical aspect of memory, for example, memory refreshing and the memory page table.
For example, the application generally has no way to understand if the memory is losing reliability due to the limited data retention or to the limited writing cycles. Thus, controlling, from the application, the reliability of a non-volatile memory associated with or coupled to the application itself may be a relevant technical problem in the field of ICCs.
Moreover, the ICC operating system cannot measure time because the ICC is not always powered on. Thus it cannot determine whether a predetermined time period, for example, five years, has elapsed to alert the application of a potential data retention problem.
On the other end, measuring the time based upon a request to the handset device, for example, requesting a current date or time with a “provide local information proactive command” as specified in 3GPP TS 31.111, may not be safe because it depends on the reliability of date or time returned by the handset device. Neither receiving an SMS nor data over other bearers on a regular basis, to detect the elapse of time, is secure. In fact, the ICC should rely on an external bearer. Moreover, this approach typically involves undesired costs for transmitting the SMS to the ICC. Thus, it may be desirable to manage the loss of reliability due to the data retention at application level, and such problem of data retention is not easily detected at the operative system layer, since the operating system cannot measure the elapsed time. Moreover, applications do not have any means to request specific actions to increase memory reliability, e.g., no way exists for an application to request the refreshment of all memory areas to extend data retention in case a data retention problem is identified.
With respect to deterioration of the hardware or connection between the ICC and the system device, in traditional machine-to-man systems, the handset may send through the corresponding machine-to-man interface a message associated with the reliability of the non-volatile memory, allowing the user to substitute the ICC. However, if the ICC is connected to a system device with a M2M interface, no machine-to-man interface is available to alert a user to substitute the ICC. Thus, the known method cannot react to a loss of reliability of the memory when the ICC is used for a M2M application.
In other words, the problem of the prior art lies in that although the non-volatile memory (NVM) in the ICC has constraints on a limited number of updates and a limited time for data retention, the application has no way of knowing the status of the NVM because no interfaces are provided by the ICC OS.
Thus, it may be desirable to provide a method and a system for controlling possible loss of reliability of non-volatile memories incorporated into an ICC, especially due to the limited data retention of such memory, to the limited writing cycles of the memory, and to possible deterioration of the hardware or connection with the device coupled to the ICC. It may also be desirable to improve the reliability of the non-volatile memory in a plurality of scenarios in which the corresponding ICC is used, including man-to-machine applications and machine-to-machine applications.